<html>
<head><meta charset="utf-8"><title>Segfault recovery UB? · general · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/index.html">general</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html">Segfault recovery UB?</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="209854712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209854712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Braden Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209854712">(Sep 12 2020 at 02:32)</a>:</h4>
<p>Is a segfault recovering UB? There are situations (especially in emulation) where some code might make use of mapped memory with <em>intentional</em> read/write to unwritable/readable memory. In these cases, they use the segfault handler to detect that they landed in a bad space, and simply ignore the fault itself, recovering from it.<br>
I imagine, though, that this is a very extreme case of UB. (As for examples of where this trick is used, look at how the Dolphin emulator handles mapping the Gamecube/Wii's memory.)</p>



<a name="209855145"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209855145" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Braden Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209855145">(Sep 12 2020 at 02:46)</a>:</h4>
<p>Thinking it over more, the entire mechanism used feels like a huge UB-fest.</p>



<a name="209863116"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209863116" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209863116">(Sep 12 2020 at 04:03)</a>:</h4>
<p>this is less 'UB' as in 'guarenteed to never work' and more 'the rust spec has nothing to say about it' I think</p>



<a name="209863117"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209863117" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209863117">(Sep 12 2020 at 04:03)</a>:</h4>
<p>AFAIK signals aren't part of the language</p>



<a name="209863118"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209863118" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209863118">(Sep 12 2020 at 04:03)</a>:</h4>
<p>(assuming this unwritable/unreadable memory is <em>not</em> null)</p>



<a name="209864040"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209864040" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209864040">(Sep 12 2020 at 04:32)</a>:</h4>
<p>It <em>might</em> be possible if you hide a bunch of it behind the allocator.  The allocator makes an "object" (from the sense of where you can <code>offset</code> things) and I think from Rust's perspective you can plausibly index into that without Rust having anything to complain about, though of course the signal handling and such to go with it is totally outside of what Rust would probably ever specify...</p>



<a name="209877856"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209877856" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209877856">(Sep 12 2020 at 11:46)</a>:</h4>
<p>Not specified behavior is usually spec'd as UB, I think.</p>
<p>I guess this is done for performance?</p>



<a name="209878216"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209878216" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209878216">(Sep 12 2020 at 11:56)</a>:</h4>
<p>Shouldn't there be room for implementation / hardware defined behavior? Otherwise things like MMIO become impossible</p>



<a name="209878233"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209878233" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209878233">(Sep 12 2020 at 11:57)</a>:</h4>
<p>or really anything that's actually dealing with the hardware</p>



<a name="209878558"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209878558" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209878558">(Sep 12 2020 at 12:04)</a>:</h4>
<p>I would expect us to leave such room explicitly, rather than by omission.</p>



<a name="209879556"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209879556" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209879556">(Sep 12 2020 at 12:31)</a>:</h4>
<blockquote>
<p>Not specified behavior is usually spec'd as UB, I think.</p>
</blockquote>
<p>No, that's only in C: <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB">https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB</a></p>



<a name="209880992"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209880992" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209880992">(Sep 12 2020 at 13:10)</a>:</h4>
<p>I am not sure what you mean to cite there -- it certainly is true that I (and Ralf) would like our eventual spec to be complete</p>



<a name="209880995"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209880995" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209880995">(Sep 12 2020 at 13:11)</a>:</h4>
<p>but I imagine that we will still have a clause of "if it's not in here, that's a bug in the spec, but it's still UB"</p>



<a name="209881174"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881174" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881174">(Sep 12 2020 at 13:16)</a>:</h4>
<p>If UB is interpreted the way modern C compilers do, that is as a license for optimization, then that would be a very bad idea</p>



<a name="209881192"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881192" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881192">(Sep 12 2020 at 13:17)</a>:</h4>
<p>The fallback should be something like hardware-defined behavior. "This does something, we're not sure what, but you (the compiler) are not licensed to not do it or reorder this operation in any way"</p>



<a name="209881242"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881242" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881242">(Sep 12 2020 at 13:19)</a>:</h4>
<p>That is certainly <em>an</em> option but seems very restrictive -- I also don't see much advantage for anyone to that.</p>



<a name="209881250"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881250" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881250">(Sep 12 2020 at 13:19)</a>:</h4>
<p>That's the point. It provides an incentive to complete the spec to unlock more optimizations</p>



<a name="209881389"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881389" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881389">(Sep 12 2020 at 13:22)</a>:</h4>
<p>The incentive is there regardless, I think, since ideally there is no UB in safe Rust and any spec omissions are then unsoundness holes, essentially.</p>
<p>I don't personally think the spec can have "hardware defined" (after all, it probably will not have a notion of hardware and be specified against an abstract machine) and I'd prefer Rust to not have "implementation defined" behavior in the spec.</p>



<a name="209881405"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881405" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881405">(Sep 12 2020 at 13:23)</a>:</h4>
<blockquote>
<p>I'd prefer Rust to not have "implementation defined" behavior in the spec</p>
</blockquote>
<p>I wsa thinking about something like this to allow stabilizing <code>rustc_on_unimplemented</code> as an optional feature or something like that</p>



<a name="209881412"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881412" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881412">(Sep 12 2020 at 13:23)</a>:</h4>
<p>to allow better diagnostics with rustc, but not necessarily require other implementations honor it</p>



<a name="209881460"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881460" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881460">(Sep 12 2020 at 13:24)</a>:</h4>
<p><code>#[pragma::rustc_on_unimplemented]</code></p>



<a name="209881465"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881465" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881465">(Sep 12 2020 at 13:24)</a>:</h4>
<p>The way "hardware defined" works in formal models is you have IO edges in the execution graph, producing an interaction tree rather than a simple turing machine like execution in vacuo</p>



<a name="209881470"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881470" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881470">(Sep 12 2020 at 13:24)</a>:</h4>
<p>you have to do something like this anyway for regular IO</p>



<a name="209881527"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881527" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881527">(Sep 12 2020 at 13:26)</a>:</h4>
<p>To some extent, though it may be that "regular IO" is either assembly or C FFI, which is likely loosely a black box -- kind of hardware defined, I guess, but not how I'd look at it</p>



<a name="209881545"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881545" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881545">(Sep 12 2020 at 13:27)</a>:</h4>
<p>But even regular memory access can be literally IO (in the case of MMIO) or figuratively IO (in the case of <code>volatile</code> accesses in C)</p>



<a name="209881729"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881729" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881729">(Sep 12 2020 at 13:32)</a>:</h4>
<p>If you use regular memory access for MMIO then that is UB. You must use <code>volatible</code> for that. In fact <code>volatile</code> was introduced for this exact reason. The compiler will optimize under the assumption that the memory access doesn't cause IO.</p>



<a name="209881854"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881854" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881854">(Sep 12 2020 at 13:36)</a>:</h4>
<p>Right, that sounds like a good example of explicit UB</p>



<a name="209881855"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209881855" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209881855">(Sep 12 2020 at 13:36)</a>:</h4>
<p>as in, you write that in the spec</p>



<a name="209882222"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209882222" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209882222">(Sep 12 2020 at 13:46)</a>:</h4>
<p>I don't think the C spec actually actively states it. Instead I only found an explicit mention that volatile accesses have side-effects. Of course every good spec would explicitly allow it rather than not disallow it.</p>



<a name="209884571"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209884571" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209884571">(Sep 12 2020 at 14:55)</a>:</h4>
<p>I can say that <code>volatile</code> <em>does</em> work for MMIO in rust, and there's quite a few people who would get out the torches and pitchforks if that ever changed. I'm not worried about that particular point.</p>



<a name="209895409"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209895409" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209895409">(Sep 12 2020 at 19:08)</a>:</h4>
<p>I think UB should be explicitly undefined behavior only. Unspecified behavior is a gap in the spec and not the same as UB. It also not implementation defined behavior either. It's just unspecified and nothing more and nothing less. Any unspecified behavior might at any point in time be specified as UB or as well defined behavior. This also means that if it's unspecified you can't do any reasoning about it which means for the rust programmer it's like UB. BUT for the rust compiler programmer it's not the same as they can't take advantage of it. Or at least that is how I think it should be.</p>
<p>Furthermore the way I see it currently rust has a lot of partial/vague specified behavior around e.g. it's memory model. I.e. while not fully/properly specified we know that certain properties will be specified as not being UB and as working in roughly some already known ways. If we would treat unspecified behavior as UB many rust programs using unsafe code would turn out to be full of UB, even through they are not.</p>
<p>While assuming that we will have a complete spec is nice it's also unrealistic as new hardware and instructions are added all the time so we will frequently find new specification gaps or unearth older previous overlooked ones. So I beehive it's very important to treat UB and unspecified behavior differently. Especially if we get additional alternative backend or rust implementations.</p>



<a name="209940122"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209940122" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209940122">(Sep 13 2020 at 17:07)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/122651-general/topic/Segfault.20recovery.20UB.3F/near/209878216">said</a>:</p>
<blockquote>
<p>Shouldn't there be room for implementation / hardware defined behavior? Otherwise things like MMIO become impossible</p>
</blockquote>
<p>that's what volatile accesses are for</p>



<a name="209940168"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209940168" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209940168">(Sep 13 2020 at 17:08)</a>:</h4>
<p>and even those are assume to be reorderedable wrt other non-side-effecting operations</p>



<a name="209940217"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209940217" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209940217">(Sep 13 2020 at 17:09)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/122651-general/topic/Segfault.20recovery.20UB.3F/near/209881854">said</a>:</p>
<blockquote>
<p>Right, that sounds like a good example of explicit UB</p>
</blockquote>
<p>no, volatile is not explicit UB, it is way more complicated than that.<br>
an example of explicit UB is: "a memory access must be fully in-bounds of some allocation, or else it is UB."</p>



<a name="209948065"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209948065" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209948065">(Sep 13 2020 at 20:20)</a>:</h4>
<p>You misunderstood my statement. I meant that plain memory access out of bounds is a perfect example of explicit UB</p>



<a name="209948070"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209948070" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209948070">(Sep 13 2020 at 20:21)</a>:</h4>
<p><code>volatile</code> access is not UB and should not be</p>



<a name="209972791"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209972791" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209972791">(Sep 14 2020 at 07:33)</a>:</h4>
<p><code>volatile</code> access still must be in-bounds, I am pretty sure</p>



<a name="209972888"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209972888" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209972888">(Sep 14 2020 at 07:35)</a>:</h4>
<p>as in, this is UB:</p>
<div class="codehilite"><pre><span></span><code><span class="kd">let</span><span class="w"> </span><span class="n">ptr</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nb">Box</span>::<span class="n">into_raw</span><span class="p">(</span><span class="nb">Box</span>::<span class="n">new</span><span class="p">(</span><span class="mi">3</span><span class="p">));</span><span class="w"></span>
<span class="nb">drop</span><span class="p">(</span><span class="nb">Box</span>::<span class="n">from_raw</span><span class="p">(</span><span class="n">ptr</span><span class="p">));</span><span class="w"></span>
<span class="n">ptr</span><span class="p">.</span><span class="n">volatile_write</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span><span class="w"></span>
</code></pre></div>



<a name="209972928"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209972928" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209972928">(Sep 14 2020 at 07:35)</a>:</h4>
<p>Are you sure? That seems really hard to justify</p>



<a name="209972995"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209972995" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209972995">(Sep 14 2020 at 07:36)</a>:</h4>
<p>I guess the compiler will still reason about what memory is not touched by a volatile write</p>



<a name="209973010"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973010" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973010">(Sep 14 2020 at 07:37)</a>:</h4>
<p>compilers assume that <code>volatile</code> are normal memory accesses that just also have some unknown side-effects -- crucially, side-effects that do not interact with memory itself</p>



<a name="209973029"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973029" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973029">(Sep 14 2020 at 07:37)</a>:</h4>
<p>compilers are free to reorder volatile with non-volatile accesses</p>



<a name="209973043"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973043" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973043">(Sep 14 2020 at 07:37)</a>:</h4>
<p>so they assume that no memory except for <code>[ptr, ptr+size)</code> is affected</p>



<a name="209973069"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973069" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973069">(Sep 14 2020 at 07:37)</a>:</h4>
<p>So <code>asm!("", "memory")</code> is strictly more powerful than a volatile write</p>



<a name="209973120"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973120" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973120">(Sep 14 2020 at 07:38)</a>:</h4>
<p>oh no, <em>that</em> can of worms again^^</p>



<a name="209973142"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973142" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973142">(Sep 14 2020 at 07:38)</a>:</h4>
<p>is that even modeled the same as a volatile write?</p>



<a name="209973161"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973161" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973161">(Sep 14 2020 at 07:39)</a>:</h4>
<p>the answer is loooong. could write a book about it.^^</p>



<a name="209973163"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973163" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973163">(Sep 14 2020 at 07:39)</a>:</h4>
<p>calling it a "compiler barrier" seems to describe the effect, not the meaning</p>



<a name="209973165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973165">(Sep 14 2020 at 07:39)</a>:</h4>
<p>the short version is "no, not at all"</p>



<a name="209973169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973169">(Sep 14 2020 at 07:39)</a>:</h4>
<p>see <a href="https://github.com/rust-lang/rfcs/pull/2360">https://github.com/rust-lang/rfcs/pull/2360</a> for some discussion</p>



<a name="209973340"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973340" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973340">(Sep 14 2020 at 07:41)</a>:</h4>
<p>but then, they are probably somewhat related, but certainly not the same -- see <a href="https://github.com/rust-lang/rfcs/pull/2850#issuecomment-581704306">this discussion</a></p>



<a name="209973353"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973353" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973353">(Sep 14 2020 at 07:42)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/122651-general/topic/Segfault.20recovery.20UB.3F/near/209972888">said</a>:</p>
<blockquote>
<p>as in, this is UB:</p>
<div class="codehilite"><pre><span></span><code><span class="kd">let</span><span class="w"> </span><span class="n">ptr</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nb">Box</span>::<span class="n">into_raw</span><span class="p">(</span><span class="nb">Box</span>::<span class="n">new</span><span class="p">(</span><span class="mi">3</span><span class="p">));</span><span class="w"></span>
<span class="nb">drop</span><span class="p">(</span><span class="nb">Box</span>::<span class="n">from_raw</span><span class="p">(</span><span class="n">ptr</span><span class="p">));</span><span class="w"></span>
<span class="n">ptr</span><span class="p">.</span><span class="n">volatile_write</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span><span class="w"></span>
</code></pre></div>


</blockquote>
<p>I think I read somewhere that if there is a non-volatile access to a memory location all (future) volatile accesses can be interpreted as being non-volatile. This would meant the snippet is interpreted as having a regular write.</p>



<a name="209973594"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973594" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973594">(Sep 14 2020 at 07:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/122651-general/topic/Segfault.20recovery.20UB.3F/near/209973163">said</a>:</p>
<blockquote>
<p>calling it a "compiler barrier" seems to describe the effect, not the meaning</p>
</blockquote>
<p>yes, exactly. :) that's the right mindset IMO. the meaning is hard to pin down, though.</p>



<a name="209973714"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209973714" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209973714">(Sep 14 2020 at 07:46)</a>:</h4>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/122651-general/topic/Segfault.20recovery.20UB.3F/near/209973353">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/122651-general/topic/Segfault.20recovery.20UB.3F/near/209972888">said</a>:</p>
<blockquote>
<p>as in, this is UB:</p>
<div class="codehilite"><pre><span></span><code><span class="kd">let</span><span class="w"> </span><span class="n">ptr</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nb">Box</span>::<span class="n">into_raw</span><span class="p">(</span><span class="nb">Box</span>::<span class="n">new</span><span class="p">(</span><span class="mi">3</span><span class="p">));</span><span class="w"></span>
<span class="nb">drop</span><span class="p">(</span><span class="nb">Box</span>::<span class="n">from_raw</span><span class="p">(</span><span class="n">ptr</span><span class="p">));</span><span class="w"></span>
<span class="n">ptr</span><span class="p">.</span><span class="n">volatile_write</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span><span class="w"></span>
</code></pre></div>


</blockquote>
<p>I think I read somewhere that if there is a non-volatile access to a memory location all (future) volatile accesses can be interpreted as being non-volatile. This would meant the snippet is interpreted as having a regular write.</p>
</blockquote>
<p>I do not think that is true at all though, mixed accesses should be fine (albeit poorly defined, in terms of how the non-volatile accesses are ordered wrt the volatile ones).<br>
it's just that for MMIO locations, <em>all</em> accesses should be volatile, so the rust docs used to say something like "usually, it is a bug to mix volatile and non-volatile accesses in one location" (I forgot the exact wording). but this had people <em>really confused</em> as they thought this was a clause about UB, so we removed it again.</p>



<a name="209974296"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209974296" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209974296">(Sep 14 2020 at 07:54)</a>:</h4>
<p>It seems conceivable that MMIO could cause memory other than the written pointer to be modified. Is the idea that all such memory must only be touched by volatile reads? And presumably volatile reads can return anything, so it is impossible to (without UB) observe the data in memory at MMIO regions</p>



<a name="209975408"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209975408" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209975408">(Sep 14 2020 at 08:07)</a>:</h4>
<blockquote>
<p>It seems conceivable that MMIO could cause memory other than the written pointer to be modified. Is the idea that all such memory must only be touched by volatile reads?</p>
</blockquote>
<p>basically, yes. you can also enforce synchronization with compiler barriers.</p>



<a name="209998106"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/209998106" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#209998106">(Sep 14 2020 at 12:40)</a>:</h4>
<p>Given that we are already off topic I was wondering do you need <code>volatile</code> read/write for shared memory?</p>
<ul>
<li>
<p>My fist idea was yes: As if the compiler does realize that you e.g. only write but never read to that memory slice it can just optimize away the write.</p>
</li>
<li>
<p>My second idea was: But that compiler can never prove write/read only access as a reference to that memory was passed to the program from a system function you link against.</p>
</li>
</ul>
<p>So now I'm not really sure about it.</p>
<p>(To be clear let's assume that some mechanism is used to synchronize access, let's furthermore assume that we pass the memory around in a type which internally use <code>UnsafeCell&lt;[u8]&gt;</code>, lastly lets assume we do properly make sure to not write from a different process to the memory while the first process has a reference into the <code>UnsafeCell</code> i.e. "normal" read-caching constraints similar to a <code>Mutex&lt;[u8]&gt;</code> do apply, if not we surely would need <code>volatile_read</code>).</p>



<a name="210013146"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210013146" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210013146">(Sep 14 2020 at 14:31)</a>:</h4>
<p>Going back to <span class="user-mention" data-user-id="277614">@Braden Nelson</span>'s original question: yes you can absolutely do this safely if you use inline assembly and a signal handler. Have a look at how the linux kernel does this: <a href="https://github.com/torvalds/linux/blob/856deb866d16e29bd65952e0289066f6078af773/arch/riscv/include/asm/uaccess.h#L124">https://github.com/torvalds/linux/blob/856deb866d16e29bd65952e0289066f6078af773/arch/riscv/include/asm/uaccess.h#L124</a></p>



<a name="210013314"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210013314" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210013314">(Sep 14 2020 at 14:32)</a>:</h4>
<p><span class="user-mention" data-user-id="209646">@Philipp Korber</span> I think the compiler can already reason about escape through "normal" methods like passing a pointer to external code. It is only when you have methods like "magically guessing the address" that you need volatile to avoid the compiler analysis from concluding wrong things</p>



<a name="210013680"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210013680" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210013680">(Sep 14 2020 at 14:35)</a>:</h4>
<p>But if it is shared memory in the sense of multithreaded access, then you'd better be using synchronization or else you will get UB (and the synchronization is what will tip the compiler off not to optimize too much in this case). So I don't think volatile is needed here</p>



<a name="210014037"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210014037" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210014037">(Sep 14 2020 at 14:37)</a>:</h4>
<p><span class="user-mention" data-user-id="277614">@Braden Nelson</span> A better explanation here: <a href="https://github.com/torvalds/linux/blob/master/Documentation/x86/exception-tables.rst">https://github.com/torvalds/linux/blob/master/Documentation/x86/exception-tables.rst</a></p>



<a name="210014390"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210014390" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210014390">(Sep 14 2020 at 14:39)</a>:</h4>
<p>Except in user mode you'll need to use the uc_mcontext from the signal handler to find the eip value at which the fault occurred.</p>



<a name="210016917"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210016917" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210016917">(Sep 14 2020 at 14:54)</a>:</h4>
<p><span class="user-mention" data-user-id="271719">@Mario Carneiro</span>  I mean multi-<em>process</em> shared memory.   Sure synchronization is necessary and I assume it exists in the context of this question.</p>



<a name="210017068"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210017068" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210017068">(Sep 14 2020 at 14:55)</a>:</h4>
<p>I'm saying that explicit synchonization alleviates the need for volatile, since it has a similar effect (but better calibrated for the actual use case)</p>



<a name="210017350"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210017350" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210017350">(Sep 14 2020 at 14:57)</a>:</h4>
<p>I need to double check the spec but I don't think C11 style atomics are limited to synchronizing within the process</p>



<a name="210019026"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210019026" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210019026">(Sep 14 2020 at 15:08)</a>:</h4>
<p>I just wanted to make sure the is no gotcha wrt. multiprocessing, I'm reasonable familiar with multithreading but have hardly any experience with sharing memory between processes.</p>



<a name="210019474"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210019474" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210019474">(Sep 14 2020 at 15:11)</a>:</h4>
<p>Looking  into it, it seems that C++ 11 atomics behavior wrt. inter-process communication is undefined. But on platforms like Linux/x86 I would be surprised if the primitive atomic operations don't work, at least as long as they are not emulated (which they should not be in x86).</p>
<p>Thanks btw.</p>



<a name="210020077"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210020077" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210020077">(Sep 14 2020 at 15:15)</a>:</h4>
<p>Through there seems to be a footnote which says the implementation should not depend on any per-process state so I guess it is well defined to work but through a footnote <span aria-label="shrug" class="emoji emoji-1f937" role="img" title="shrug">:shrug:</span></p>
<p>It also explicitly mentioned inter-process shared memory.</p>



<a name="210020531"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210020531" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210020531">(Sep 14 2020 at 15:19)</a>:</h4>
<p>Footnote: <a href="https://eel.is/c++draft/atomics.lockfree#5">https://eel.is/c++draft/atomics.lockfree#5</a></p>



<a name="210021893"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210021893" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210021893">(Sep 14 2020 at 15:28)</a>:</h4>
<p>(TL;DR: atomics can be used for inter-process synchronization via shared memory iff they are guaranteed to be lock-free, i.e. <code>ATOMIC_&lt;TYPE&gt;_LOCK_FREE == 2</code> for your target)</p>



<a name="210034169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210034169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210034169">(Sep 14 2020 at 17:04)</a>:</h4>
<p><span class="user-mention" data-user-id="209646">@Philipp Korber</span> yeah, multi-process shared memory is a tricky question. in particular if you consider the processes not trusting each other. there's two huge threads in the UCG tracker about it, one sec...</p>



<a name="210034266"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210034266" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210034266">(Sep 14 2020 at 17:05)</a>:</h4>
<p><a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/152">https://github.com/rust-lang/unsafe-code-guidelines/issues/152</a>, and <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/33">https://github.com/rust-lang/unsafe-code-guidelines/issues/33</a>. well the latter is more about volatile in general.</p>



<a name="210034407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Segfault%20recovery%20UB%3F/near/210034407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Segfault.20recovery.20UB.3F.html#210034407">(Sep 14 2020 at 17:06)</a>:</h4>
<p>if you ignore the "trust" problem, I think using atomics should be enough (though <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/215">https://github.com/rust-lang/unsafe-code-guidelines/issues/215</a> sheds some doubt on that). but then one process could make the other read uninitialized memory, quickly leading to UB, so that's not a good model for mutually distrusting processes.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>